WORD DOCUMENTS:

- kax 4/11/08 14:42 - Nowhere near complete. Still integrating all the bits. Doing my best to keep the numbering decent. NOTE the DOCX is the real file. The other one is included for luddites. Next update in 40 mins.

- kax 4/11/08 15:37 - Includes everything on this page. No good formatting yet. I'm going to email around a list of sections that are still empty.

System Overview

Cassia talking scales is a portable microprocessor-controlled scale designed to be used by the average consumer with ease of use for the visually impaired. It can be modified by the client to display in either grams or ounces with a weight limitation of 1kg load (1000grams, 35.2739 ounces) at any given time.


All user interface is driven by a keypad list interface. Options are listed and results displayed on an LCD screen as well as spoken by the scales through the integrated speaker.

Document Overview

A short “road map” of the document, to provide an orientation for the reader. Summarise the purpose and contents of this document.

Reference Documents

The present document is prepared on the basis of the following reference documents, and should be read in conjunction with them.
“PIC18F452 Data Sheet”
“Winbond TTS Manual”
“Altronics Keypad interpereter”
"MM74C922 16 Key Encoder Datasheet " Encoder chip Datasheet
"ALTRONICS Z7000A LCD Module Datasheet"
"Samsung KS0066U LCD Controller Datasheet"
"Peer Ouwehand material on how to control HD44780-based displays"

—. “CAN Specification 2.0”. Robert Bosch GmbH, Stuttgart, September 1991.
—. “OMG Unified Modeling Language Specification”, vers.1.3, June 1999.

Acronyms and Abbreviations

Table 1-1 lists the acronyms and abbreviations used in this document.
Table 1-1: Acronyms and Abbreviations.

Acronym	Meaning
ACFR	Australian Centre for Field Robotics
CTS	Continuous or Continuously
PDL	Program Design Language
TBD	To Be Done, also To Be Defined
TLA	Three Letter Acronym
USYD	The University of Sydney
WTF	What The Fork?
TTS	Text To Speech
GG	Good Game
PIC	PIC18F542
LCD	Liquid Crystal Display
MPU	Microprocessor Unit
A/D	Analogue to Digital
ASCII	American Standard Code for Information Interchange

System Description

This section is intended to give a general overview of the basis for the talking scale system design, of its division into hardware and software modules, and of its development and implementation.

Introduction

Give a technical description of the function of the whole system, in terms of its constituent parts, here termed modules. Generally, a module will have hardware and software parts.

Voltage Measurement Module

The scales hardware is a cantilever beam approximately 30cm long and 6cm wide. When masses are added to a pan on the end of the beam, the deformation of the beam is measured by 4 strain gauges located near the fixed end of the beam. The resistance of these sensors is measured, and then normalised to a 0-V++ range by an op-amp.
The voltage produced is measured by the A/D converter on the PIC (PORTA<1>), and recorded for further processing at a later time. The number saved is a 10-bit binary number, with 0 representing 0V, and 1024 representing V++ (negative voltages will be interpreted as 0V).
V++ is generated by a variable voltage divider circuit. This can be manually adjusted using two trimpots (coarse and fine), to generate a voltage between 0 and 5V. By default this is set to 3.7V, allowing the full range of 0-1000g. If the scales hardware changed or needed to be adjusted, this enables an easy way to keep the system performing to specification.

Calibration and Voltage to Weight Conversion

Based upon a linear gradient and intercept that is set during the calibration mode, the function getWeight() will look at the last voltage stored and convert it to a value of either grams or ounces (using a separate linear equation for the desired unit). Once converted, the N most recent values of mass are saved to a circular buffer, which is averaged and then converted into a string of characters to be displayed on Hyperterm or the LCD.

Calibration mode allows a technical user to adjust the accuracy of the scales. After entering factory mode, the user may enter calibration mode. The scales will record the voltage generated by the scales when there is no mass on it, and also when some non-zero mass is placed on the scales. Using the serial receive capability via hyperterm, the user is prompted to enter the known mass on the scales, which is interpreted as a number. These two datapoints are passed to the calibrate() function, which will generate a new gradient and x-intercept that will be used for future weighings.

String Storage and Retrieval

There is a very limited amount of available RAM on the PIC, so most of the strings that are used by the text to speech, LCD display, and the serial transmission functions are stored in the FLASH memory until they are ready to be used. When a function wants to send one of these strings, they access it via the function "get_rom_string(unsigned rom char*)", which will fetch the sequence of characters via the TLATCH register, and then copy the string to a static location in local memory where other parts of the program can send it as if it were simply available in RAM. Since this location is shared by many functions, these values are copied to one of the output streams as soon as it is possible, because there is no guarantee that this temporay string will not have changed.

Operational Scenarios

Describe how the system is to be used. There may be several different ways that it can be used, perhaps involving different users, or classes of user. Present use case diagrams here if you are using them. Each operational scenario is a part through a use case diagram – a way of using the system, with different outcomes or methods of use.
You should also consider the various failures that may occur, and the consequences of these failures.

System Requirements

The operational scenarios considered place certain requirements on the whole something system, and on the modules that comprise it.
Statement of requirements that affect the system as a whole, and are not restricted to only a subset of its modules.

Module Design

Describe the breakdown of the design into functional modules. Each module probably contains both software and hardware.
Then include a section like the following (2.5) for each module. Not all of the sub-headings may be relevant for each module.

MODULE DESIGN: TTS ---> kax 3/11/08 17:50
MODULE DESIGN: Serial RC --> kax 3/11/08 17:52
MODULE DESIGN : Keypad
Module Design (Requirements and Conceptual Design): Serial transmit -Michael
Conceptual Design: Variance calculation. (Not sure if this should be a module in itself, or part of a larger "weight" module) -Michael

Module design, Conceptual design, and Software design:
Calibration:
A/D Converter:
-Duncan

LCD everything: - Michelle
Stuff about the Scales hardware: Scales.doc - Alex (Shout at me if anything is wrong).

Module Requirements: Module X

The operational scenarios considered place certain requirements on the something system, and on the modules that comprise it.

Functional Requirements

This section describes the functional requirements of Module X – those requirements that must be met if the module (and system) is to function correctly.

Inputs

Describe each external input, including signal encoding and timing, message encoding and timing, protocols, file formats, protection against input errors, etc, as relevant.

Process

Describe the internal signal transformations and/or computer processing functionality required within the module, required performance limits, and error tolerances as appropriate.

Outputs

Describe outputs that must be produced for the module to function correctly, including timing, frequency, protocols, etc as relevant.

Timing

Any required timing or latency specifications that must be met.

Failure modes

Required functionality (if any) in the event of failure of various nominated components.

Non-Functional (Quality of Service) Requirements

Non-functional requirements do not need to be met for the device to have basic function, but are required to provide specific levels of performance or engineering quality.

Performance

Requirements such as computational loop time, accuracy, etc.

Interfaces

Qualities that are desirable in input and output interfaces, but are not required for functionality.

Design Constraints

Practical or commercial considerations, such as programming languages, processor or other hardware, etc.

Conceptual Design: Module X

Now, for each module, give the outline of how it will work. In this section it is appropriate to present

• The rationale for the design decisions that were made – why things
  were designed the way they were
• block diagrams,
• mathematical models and algorithms,
• data flow diagrams
• state-transition diagrams
• listings of input and output formats
• listings of message and data formats
• responses to identifiable error conditions
• responses to identifiable failure conditions

as appropriate for each module.

Assumptions Made

State any assumptions made.

Constraints on Module X Performance

State any constraints that may prevent the design from satisfying its requirements.

User Interface Design
User interface is available from three states: local, factory and remote settings. Each state uses a different input setting and level of accessibility.

The User Interface is based on a simple feedback structure where the user can go in and alter states such as base weight, measurement type (grams or ounces) and so forth according to their needs. Once input command is received, it changes structure and corresponding code to go with new input and will stay that way until the system is turned off or reset.

The design of user interface is broken down in options that the user can choose from based on what state they are in. The code first checks the state the user is in. After this, it checks the function the user has chosen (such as weight, tare and so forth). Each function then corresponds to a different display and speech module. New functions are cross-referenced to previously received data and then displayed.

The user is also given power over the speech module. As well as being able to choose state and setting, they have the added functionality of getting the system to repeat what was said (by pressing “speak” command on the keypad) or to mute (pressing “mute” command on keypad) the system. Pressing the speak button will overwrite the mute command.

Upon restart, the LCD module is cleared to display the menu back to the default setting (that is, local mode).

Classes of User
User classes are defined by local, remote and factory settings. Remote and factory settings are displayed through the hyperterminal and uses a keyboard for interface whilst the local setting uses the keypad and LCD. Local and Remote settings contain mostly the same functionality whiles factory settings allows access to more sensitive calculation procedures such as calibration and statistics.
Changes between settings is done by the HyperTerminal. The system begins start up in the local mode. If the Hyperterminal is activated, keyboard controls can be used to switch between modes. Pressing ‘l’ will send to local mode, pressing ‘r’ will send to remote mode and pressing ‘f’ will send to factory mode.

Interface Design: Local Setting
User Inputs and Outputs
In local mode, the user interfaces with the system via the keypad and LCD. Options available can be seen in the following figure:


Figure 1 Keypad option layout
1. Weight:
Pressing this key leads to a prompt on the LCD and from the TTS to load the first mass. The module calibrates this weight according the calibration settings (see factory mode) and outputs an answer to the LCD. The TTS also received this calibration and outputs through the speaker the weight output.

2. Count:
In count mode, the first input will be to place a number of similar objects into the scale. A prompt will then take place to ask how many items are in the scales. Upon answering, the module calculates the mass of a single item. There is then a prompt for the second mode for the user to add items and calculates from previous measurements how many items are in this new mode.

3. Tare:
Tare mode allows the user to set a zero reference point. This is primarily used for adding up weights.

In this mode, the user is prompted to add weights into the system. After this, they chose to ‘tare’ the value. This resets the weight scale to zero. They can then add in more weights which value will be displayed in correspondence to the zero point set by the tare.

4. Switch units
Pressing this button switches between grams or ounces as a unit of measurement output. All measurements from this point on will be displayed according to the option set here.

8. Mute
Pressing this button deactivates the speak module

9. Speak
Pressing this option repeats the last statement made by the TTS. This allows the user to rehear any instruction they may have missed.
This button can also be pressed to deactivate the mute option.

*. Back
This button allows the user to go back to the menu mode on the LCD

#. O.k.
Pressing this button is received as a positive command. It is pressed when a task has been undertaken and the user is ready to continue. For example, it is pressed when the user is given the prompt to add a weight and they have finished adding the weight.


For the four main states, the LCD displays the state so that the user is made aware of what mode they are in.

Input Validation and Error Trapping

The LCD will express the state in validating the user input. Prompts from the TTS also verify the state due to the type of mode set (if not in mute). At times a key may need to be pressed twice to send to that mode.
Operator errors are not caught in this part of the module.

Interface Design: Remote and Factory Setting
Remote Setting: User Inputs and Outputs
Here the user has four options. The fifth main option, calibrate, should not be used in this mode as it’s not programmed for display on the LCD. All options are available from user input on the keyboard. Options and results are displayed through the HyperTerminal.

All options are activated by pressing their first letter (e.g for ‘weigh’ option, pressing ‘w’ on the keyboard activates this state.)


‘w’eigh:
Weigh mode is the basic and most useful mode of the system. Upon entering this mode, the TTS and text prompts the user to place the weight they want measured onto the scale. It then calibrates this weight according the the calibration settings (see factory mode) and outputs an answer on the screen. The TTS also received this calibration and outputs through the speaker the weight output.

‘c’ount:
In count mode, the first input will be to place a number of similar objects into the scale. A prompt will then take place to ask how many items are in the scales. Upon answering, the module calculates the mass of a single item. There is then a prompt dor the second mode for the user to add items and calculates from previous measurements how many items are in this new mode.

‘t’are:
Tare mode allows the user to set a zero reference point. This is very useful for adding up weights.

In this mode, the user is prompted to add weights into the system. After this, they chose to ‘tare’ the value. This resets the weight scale to zero. They can then add in more weights which value will be displayed in correspondence to the zero point set by the tare.

Change ‘u’nits
This mode changes between using grams or ounces. By choosing this option, the user can now choose to switch between the two possibilities by following the prompts. All measurements from this point on will be displayed according to the option set here.



For all options, the user is made aware of what state they are in by a display in the HyperTerminal displaying the state before the result. Reading this line instantly conveys what mode is currently active.


Factory Setting: User Inputs and Outputs
Factory setting is similar to remote setting with inputs again from the keyboard. It has the same functionality as above with the additional system of ‘calibrate’, ‘statistics’, ‘raw’ and ‘samples’. These options are chosen by using uppercase letters.

‘C’alibrate
For the calibrate setting, the user is prompted to adjust the voltage output of the scales to a set weight. That is, to enter a known mass into the system. The user is then prompted to tell the machine the weight of this mass by typing the mass on the keyboard. By using the voltage output from the scales and adjusting to the input of what this output was stated to be, the program calibrates itself to use this ratio for all future measurements.

‘S’tatistics
Due to time limitations, this part of the module was not effectively completed.

‘R’aw
This option displays the ‘raw’ weight. Choosing this option is the factory mode version of ‘weigh’ from remote. Please refer to “Remote setting: user inputs and outputs >> ‘w’eigh” for more information regarding this option.

Sam‘P’les
This mode is similar to count mentioned in the other settings. Choosing this option allows the number of samples that contribute to a single weight estimate to be set.

Upon selecting this mode, the user is asked to set a couple of identical weights. Once this is done and entered, the user is prompted to type on the keyboard the number of units entered. The program then calculated the weight of a single unit.

The user is then prompted to empty the contents and put a new load sample in. From this sample, this module calculates the number of contents in the scale based on the previous calculation.



Once again, for each option, the user is made aware of what state they are in by a display in the HyperTerminal displaying the state before the result. Reading this line instantly conveys what mode is currently active.


Input Validation and Error Trapping
When a state is chosen, a fresh image on the HyperTerminal is generated with the state displayed and further options for the user to see. This tells the user if they have successfully chosen their new state.
If an incorrect option is chosen – that is, if a letter input is made that doesn’t correspond with a letter in the menu – then nothing happens.
If the operator chooses a wrong state, they can go back to the menu by resetting or going back by following the instructions displayed in the HyperTerminal.
The system is case sensitive. This is needed since have two ‘c’ operations: A lower case ‘c’ is used for the count option while uppercase ‘C’ chooses the calibration mode. It is up to the user to make sure they abide by this case sensitivity in order for the system to work correctly. They will be able to tell if an error is made by the HyperTerminal showing them the option they chose.

Hardware Design

Give a detailed description of the design of hardware. The description should include mechanical drawings, location diagrams, electrical circuit schematics, circuit simulation or test results, PCB overlays, wiring diagrams, connector pin-out lists, pneumatic/hydraulic circuit diagrams,

Scope of the Something System Hardware

Statement of what is, and what is not, being designed and described here.

Hardware Design

Speech Output
(speech output hardware notes are included in the TTS document under module design)

Low Pass Filter



Pin Connections



Keypad

Power Supply

The hardware portion of this module consists of a power distribution board, which takes voltage from the power supply (in this case, the +5v and GND pins from the PIC board), and provides output to the other hardware. Each output is protected by a 47uF reservoir capacitor, which provides a buffer to the rest of the system if a single piece of hardware draws a surge of current. This is especially important because the PIC processor shares the same supply rails, and would reset if it lost power even for a short time.
The software section of this module uses the low voltage detect interrupt capability of the PIC board. In the event that the voltage to the board drops below 3V, the system will inform the user that it is about to shut down, and attempt to save the calibration and tare settings to FLASH before it runs out of power.

Computer Design

Description of computer hardware, including all interface circuitry to sensors, actuators, and I/O hardware.

Sensor Hardware

Actuator Hardware

As appropriate.

Operator Input Hardware

Operator Output Hardware

Hardware Quality Assurance

Describe any measures that were taken to control (improve) hardware quality and reliability – Heartbeats, brownout conditioning/resets, reset conditions, testing and validation, etc.

Hardware Validation

Each hardware component is tested separately using a digital multimeter and oscilloscope (as necessary) before it is integrated into the system as a whole. Due to the modular nature of the hardware design, individual components can be tested if they are suspected to be faulty and replaced individually.

Hardware Calibration Procedures

Most of the calibration issues are solvable using the software calibration procedure (above). However, in the event that the scales are not able to measure over the desired range of masses (0 - 1000g), the operational range can be extended by using the two trimpots on the Vref supply board. This will alter the maximum output voltage of the scales (which should not exceed 3.8V when 1000g is placed upon it), and allow the PIC to measure into this range.

Hardware Maintenance and Adjustment

Routine adjustment and maintenance procedures.
For all the hardware within the project, there wasn't any heavy duty adjustment and maintenance that was required of the project. The issue that were faced in this area were:

• issue of safely storing each individual component into the system box
• each component had to carefully positioned to avoid any short circuiting or interference
• protection from dust and particles
• ventilation to prevent any overheating problems
• using the multimeter to test connections to make sure each wire is properly crimped and ready to use

Software Design

The software requirements and overview have been dealt with elsewhere in this document. The present section addresses the design and implementation of the software that forms the X system.

Software Design Process

How you went about designing the software – top down, bottom up, OOD, functional view, etc.
From the beginning, an attempt was made to keep the design of the software layered - that is, the internal functions should behave identically, regardless of which input or output channels are being used. This was accomplished by using streams for both input and output. The reasoning behind this was that any input device (for example) could push instructions (as characters) to the input stream, and then interpreted as required by the rest of the program. The same was applied to the output: messages were streamed to output buffers, which could be transmitted/displayed/spoken at the appropriate rate.

The development of software was very much from the bottom up perspective. This approach was chosen to suit the needs of the team: each team member was expected to create very small, functional, robust blocks of code that could be used and reused to build the final product. Each team member was also required to document their code on a wikispace page, which would allow other team members to understand how to use their functions, and also provide a forum for peer review and criticism.

Integration was planned to start early, and be an iterative process instead of a single extensive build towards the end of the project. This was intended to allow early detection of potential problems, and also reveal shortcomings of the design that would need additional attention. However, the hardware integration was not synchronised with the software integration, and this meant that certain assumptions had to be made when putting together the software.

Software Development Environment

The tools that were used, both software (compilers, assemblers, etc) and hardware (development boards, etc.).

Software development was done on the Microchip MPLAB Integrated Development Environment version 8.10 using the MPLAB C18 compiler (MCC18) version 3.21. See http://ww1.microchip.com/downloads/en/DeviceDoc/51519B.pdf for a user's guide to the MPLAB environment and http://ww1.microchip.com/downloads/en/DeviceDoc/C18_User_Guide_51288j.pdf for a user's guide to the C18 compiler.

A Microchip ICD2 in-circuit debugger was used in conjunction with a PICDEM 2 plus prototyping/development board for software debugging and hardware development. See http://ww1.microchip.com/downloads/en/DeviceDoc/51331C.pdf for a user's guide to the ICD 2 debugger and http://ww1.microchip.com/downloads/en/DeviceDoc/51275d.pdf for a user's guide to the PICDEM 2 plus board.

Software Implementation Stages and Test Plans

Describe the way you went about implementing the software - staged implementation, pseudocode (PDL), unit testing procedures, integration testing, etc. Identify dependencies – e.g this had to be done before that, etc.

Software Quality Assurance

A free technical support hotline is available 24 hours a day, 7 days a week.

Software Design Description

Architecture

System Architecture

At a very high level, the system looks like this:
Not everything is shown on this diagram (notably input methods). The overall architecture of the system is a layered design: That is, it takes inputs from the input layer (top), and passes them to the data processing layer (middle). The middle layer also includes a state machine, which will control how the information is presented to the output layer (bottom).

General Interfaces

Where possible, interfaces between layers were handled by buffers or streams. This allowed communication to happen asynchronously – ie, different parts of the program were free to execute at different rates, and not slow the entire system down. Generally, a circular buffer (of sufficient size for the task) was allocated, with one or more functions writing to it, and others reading from it.

In the cases where the buffer was likley to overflow/underrun, flags were used to communicate this to other modules sharing the stream, so that valuable information was not lost.

Error Checking and Handling

Given the extremley interconnected nature of the functions, it was important to make sure that each function performed it's task properly and was able to detect errors so that they were not propogated to the rest of the system. Where necessary, the inputs and outputs of a function were checked for correctness (eg: non-negative, non-zero, etc) and corrected/set to default 'safe' values if possible. During the debug and integration stage, functions were required to report these errors via the serial transmit function to alert the team.

Function size and Code reuse

There is a very limited amount of both program and data memory on the PIC so wherever possible, functions were written to be generalised and reusable. The result of this was that the program (except for the monolithic state machine function 'check_state()') was built out of very small building blocks that could be easily debugged and rewritten as necessary.

Software Interface

Describe the public interface of each software module.

Serial Transmit: Input = null-terminated ASCII string. No output returned to program.

Software Components

This is a detailed view of the internal workings of each of the software modules.

Numerical User Input

For two modes: Count mode and Calibrate mode, the operational state of the input devices needs to change to allow numerical data to be received. This is accomplished by setting the global flag "num_input" to TRUE. This will change the way that key presses from the keypad are converted to characters on the input stream. For example, normally pressing the keys "1" and "4" would result in the characters "w" and "u" being placed on the input stream. However, if num_input = TRUE, then the numerical values of the keys will be placed on the stream. By keeping track of a pointer to the location on the input stream before the user began entering numbers, this string can then be null terminated by an OK/enter, and then sent to the function "atoi()" to extract the value.

Count mode

Count mode is essentially an extension of weigh mode. A known number of objects are placed on the scales, and the user then tells the program how many are present. The average weight of each object is simply calculated by dividing the total weight by the number entered by the user. Then, the user is prompted to place an unknown number of identical objects on the scales. The software will then divide the total mass of the unknown items by the previously calculated weight of an individual item - yielding the number of items.

Serial transmit


Variance calculation


Keypad Interrupt and Input

Preconditions for Software

Preconditions for System Startup

Describe any preconditions that must be satisfied before the system can be started.

Preconditions for System Shutdown

Describe any preconditions that must be satisfied before the system can be stopped.

System Performance

Performance Testing

Give the results of testing conducted to determine the characteristics and performance of the system - memory usage, loop time, system accuracy, repeatability, ease of use, etc.

State of the System as Delivered

A statement of your group’s opinion of the conformance of the system with the specification.

After the system was demonstrated there were certain areas that needed to be addressed that involved the system’s conformation to the system specifications.

Firstly the system was able to measure the weight of the item in question to a respectable level however the system was at times slow and unresponsive to commands placed by the user on the feedback of the current weight. The TTS module will be temperamental during certain moments and won’t give a response and the system would need to be resettled to get it operational again.

The count function was unpredictable as well as the system will sometimes count correctly and other time it will count incorrectly however it will usually be off by a small margin, this could be due to software failure in the algorithm or there was an overflow of data.

Another specification requirement was for the system to be used by a blind person, which was made possible through the implementation of the TTS to talk during certain intervals in the menu options and via a quick access guide printed in Braille that tells the user which mode corresponds to each button on the keypad.

Other small areas which conform to the specifications:
· Able to toggle between ounce and grams
· Able to tare
· Switch between factory and user mode

On the hardware level, the system conforms to the specifications as it was:
· Light weighted
· Low power
· Circuits were integrated via the Vero boards

The system would have been portable as well however due to hardware faults, this was not possible as the smaller PIC board could not be implemented and the bigger one had to be implemented for demonstration.

Future Improvements

Present a prioritised list of improvements to be made in future releases, giving reasons for the improvement and priority rank.

Safety Implications
According to the NSW Occupational Health and Safety Act 2000; NSW Occupational Health and Safety Regulation 2001 the following guidelines must be kept in order to maintain user safety. Team Cassia does not take any responsibility if misuse of the product as outlined here leads to damage to person(s) or to the environment.

· Do not get the product wet
It may resemble a fish tank however the electronics inside the containment unit are very sensitive and any water may and will lead to decreased functionality, short circuiting and possible harm to the user
· Keep the product out of reach of children at all times
This is not a toy. The casing can break creating sharp edges that young children may hurt themselves on. Also poking fingers through the gaps or opening the side containment can lead to electric shock.
· The product should be placed in a flat dry space, well ventilated from moisture in order to maintain ideal working conditions.
· Do not remove or alter the electronics
Team Cassia takes no responsibility for any damage to the product that takes place due to altering the circuitry. If you believe there is a hardware problem, please call our helpline and we will send someone to fix the problem or replace the unit for you. Under no circumstance should the user attempt to fix the problem themselves for their own safety.
· The unit should remain closed in order to ensure all electronics are safely tucked inside away from the outer environment where they may cause harm. The self contained unit is a protective and non conducting material so as long as no one attempts to open the unit, it should remain safe for the user.
· In case of electric shock:
o Do not attempt to touch the user
o Make sure you have adequate grounding (such as rubber soles on you feet so that you too do not become a conducting source)
o With a non conducting material (such as a wooden ruler), switch off the power at the source to shut down the voltage path.
o With a non-conductive material attempt to move the user out of the current path
o Call an ambulance if the user appears harmed in any way from the experience
· In case of electrical fire:
o DO NOT USE WATER TO PUT OUT THE ELECTRICAL FIRE
o Open all windows and doors in order to ventilate the smoke – the gas is poisonous
o If fire starts at the wall outlet, pull out the plug by the cord or turn off power at the main switch
o Call the fire department giving them all details and telling them it’s an electric fire
o If a CO2 extinguisher is available, use this to attempt to put out the fire (if the fire is small)
o If the fire becomes uncontrollable, evacuate anyone in the building and await for the fire department to arrive.

Conclusions

Appendix A: Title
A.1. Subtitle
Appendices are used for any material that is not included in the main part of the report, usually because it would be distracting to the reader.




You would normally include manufacturer’s data sheets, but please do NOT include them in this report.




Supporting calculations should also go in an appendix.




If you use Doxygen (www.doxygen.org) for code documentation, generate rich text format (RTF) output, open the RTF in Word, copy, and paste it into an appendix.




Please do place your code listings in the following 2-column section. Make sure to use a non-proportional (mono-spaced, or “typewriter”) font, such as Courier New or Andale Mono.

Place code listings here, using style “Code Appendix” The column width will fit approximately 88 characters per column.

Each file should start on a new page, or at least at the top of a new column.